The Internet Protocol (“IP”) is designed as a connectionless protocol. Therefore, IP workload balancing solutions typically treat every Transmission Control Protocol (“TCP”) connection request to a particular application, identified by a particular destination IP address and port number combination, as independent of all other such TCP connection requests. Examples of such IP workload balancing systems include Sysplex Distributor from the International Business Machines Corporation (“IBM”), which is included in IBM's z/OS and OS/390 TCP/IP implementations, and the Multi-Node Load Balancer (“MNLB”) from Cisco Systems, Inc. Workload balancing solutions such as these use relative server capacity (and, in the case of Sysplex Distributor, also network policy information and quality of service considerations) to dynamically select a server to handle each incoming connection request. However, some applications require a relationship between a particular client and a particular server to persist beyond the lifetime of a single interaction (i.e. beyond the connection request and its associated response message).
Web applications are one example of applications that require ongoing relationships. For example, consider a web shopping application, where a user at a client browser may provide his user identifier (“user ID”) and password to a particular instance of the web application executing on a particular server and then shops for merchandise. The user's browser may transmit a number of separate—but related—Hypertext Transfer Protocol (“HTTP”) request messages, each of which is carried on a separate TCP connection request, while using this web application. Separate request messages may be transmitted as the user browses an on-line catalog, selects one or more items of merchandise, places an order, provides payment and shipping information, and finally confirms or cancels the order. In order to assemble and process the user's order, it may be necessary to maintain state information (such as the user's ID, requested items of merchandise, etc.) until the shopping transaction is complete. It may, therefore, be necessary to route all of the related connection requests to the same application instance because this state information exists only at that particular web application instance. Thus, the workload balancing implementations typically must account for on-going relationships of this type and subject only the first connection request to the workload balancing process.
Another example of applications that require persistent relationships between a particular client and a particular server is an application in which the client accesses security-sensitive or otherwise access-restricted web pages. Typically, the user provides his ID and password on an early connection request (e.g. a “log on” request) for such applications. This information must be remembered by the application and carried throughout the related requests without requiring the user to re-enter it. It is therefore necessary to route all subsequent connection requests to the server application instance which is remembering the client's information. The workload balancing implementation must therefore bypass its normal selection process for all but the initial one of the connection requests, in order that the on-going relationship will persist.
The need to provide these persistent relationships is often referred to as “server affinity” or “the sticky routing problem”. One technique that has been used in the prior art to address this problem for web applications is the use of “cookies”. A “cookie” is a data object transported in variable-length fields within HTTP request and response headers. A cookie stores certain data that the server application wants to remember about a particular client. This could include client identification, parameters and state information used in an on-going transaction, user preferences, or almost anything else an application writer can think of to include. Cookies are normally stored on the client device, either for the duration of a transaction (e.g. throughout a customer's electronic shopping interactions with an on-line merchant via a single browser instance) or permanently. A web application may provide identifying information in the cookies it transmits to clients in response messages, where the client then returns that information in subsequent request messages. In this manner, the client and server application make use of connection-oriented information in spite of the connection-less model on which HTTP was designed.
Through the use of cookies, server affinity may be maintained for a session with a client. Furthermore, because server affinity may be maintained, the server may maintain state information for a session with a client. A backup server may also maintain the state information for the session for use in the event of unavailability of the original server. However, while server affinity may be maintained for the session, if the original server fails it may be difficult to route requests for the session to the correct backup server, especially if the backup server is a specific server in a group of servers and is not statically defined or may vary for different sessions to the original server.
For example, in WebSphere Application Server v. 5, HTTP routing servers may route communications for a session to a first application server based on an identification of a specific server in the communications. Other application servers in a cluster of application servers may maintain backup session state information for the session to the first application server. If the first application server fails, one of the other application servers in the cluster continues the session using the backup session state information. The backup server utilized may be selected statically, i.e. a specific one of the application servers that is established in a static configuration, or dynamically, i.e. selected on-the-fly at the time of failure of the first application server. In the situation where the backup application server is selected dynamically by the cluster of application servers, the HTTP routing server may not know which application server has been selected and, using a server to IP address table, look up the failed server as the destination to forward communications. Furthermore, the problem may become even more complex if multiple sessions are continued by different backup application server, which may be the case to maintain load balancing, and if multiple HTTP routing servers are used as the identity of the backup application server for a session may be difficult to establish a priori so that the routing application servers could be preconfigured with the backup information.